Cognitive Dimensions of Notations

classificatory schemes need to be justified in concrete terms. The dimensions concept can be justified by pointing to areas where progress is slow, as I have done above; or by criticising existing systems; or by raising design issues in relation to present growth areas. Let’s take the last, and look at OOPS. Object-oriented systems have been praised as resolving some cognitive problems (Rosson & Alpert 1988), at least in principle. I take no issue with that, but are they adequately usable yet? A fundamental claim in this paper is that system = notation + environment. Research papers on OOPS, however, offer a myriad new languages, with different ideas about the semantics of inheritance, etc., but say very little about environments. Here are some questions arising from the preceding discussion, with remarks relating to one OOPS, Smalltalk-80. I shall take the five dimensions I have described in order. 1. Are there hidden dependencies and one-way links in the structure? Smalltalk-80 scores fairly well here; most relationships can be browsed in both directions, although there are times when it would nice to make dependencies more immediately visible without having to search for them, so that they could at as reminders. However, there is little support in searching for ill-specified targets. “I want something that handles a bitmap, what can I find?” Nor is it easy to find out what kind of object can fill an instance variable slot in a method. 2. If the inheritance hierarchy viscous, or is it easy to reconstruct in a different fashion? The inheritance structure lends to be viscous. For instance, given a class Animal with many sub-classes Trout, Herring, Minnow, etc.. inserting a new class Fish between Animal and its subclasses requires many operations (add a new subclass, Fish, to Animal; move Trout to Animal, etc.) Moreover, changing the inheritance hierarchy normally means changing the pattern of class and instance variables in the hierarchy — our new class, Fish, will contain information relevant to all its subclasses, and this information will have to he extracted from its previous position in the hierarchy and brought together under the new heading. 3. Is the generative order adequately decoupled? Not in Smalltalk-80, where inheritance hierarchies must be created top-down. We lack at present any published evidence on how Smalltalk programmers work, but experts have criticised this aspect in precisely the terms I would expect, namely that when designing the inheritance hierarchy the mental order in which steps are generated is not top-down, so that the effect of the environment’s insistence on top-down working is constrictive (Goldstein & Bobrow 1981; LaLonde 1987). LaLonde’s description is that the expert first designs a specific data type, by focussing on a useful set of operations, and then that data type is positioned in a logical hierarchy. 4. Is it role-expressive? Again, not adequately; although the purpose of object-oriented programming is to clarify relations between parts of programs, one finds that relationships between methods are obscure. The only browsers provided operate on